Illlllllllilllllll 



United States Patent [19] 

Clark et al. 



US005835090A 

[ii] Patent Number: 
[45j Date of Patent: 



5,835,090 
Nov. 10, 1998 



[54] DESKTOP MANAGER FOR GRAPHICAL 
USER INTERFACE BASED SYSTEM WITH 
ENHANCED DESKTOP 

[75] Inventors: Richard L. Clark; Tom C. Martyn, 
both of Seattle, Wash. 

[73] Assignee: ETMA, Inc., Redmond, Wash. 

[21] Appl. No.: 733,224 
[22] Filed: Oct. 17, 1996 

Related U.S. Application Data 

[63] Continuation-in-part of Scr. No. 732,179, Oct. 16, 1996, 
abandoned. 

[51] Int. CI. 6 G06F3/14 

[52] U.S. CI 345/339; 345/342 

[58] Field of Search 345/339, 340, 

345/342, 343, 346, 348, 356, 326, 332, 
335, 145; 395/683 

[56] References Cited 

U.S. PATENT DOCUMENTS 

5,459,825 10/1995 Anderson et al 345/433 

5,499,334 3/1996 Staab 345/340 

5,572,649 11/1996 Elliott eta) 345/340 

5,577,187 11/1996 Mariani 345/342 

5,642,490 6/1997 Morgan et al 345/342 

5,657,463 8/1997 Bingham 345/342 

5,668,997 9/1997 Lynch -Freshner et al 395/683 



5,694,150 12/1997 Sigonaetal 345/145 

5,694,561 12/1997 Malamud et al 345/346 

5,699,535 12/1997 Amro 345/127 

5,748,189 5/1998 Trueblood 345/331 

6,664,002 10/1996 Brown 345/326 

OTHER PUBLICATIONS 

Thorn Hogan, The Programmer's PC Sourcebook, pp. 
261-270, 353-360, and 423-430 Microsoft Press, 1988. 

Primary Examiner — Matthew M. Kim 
Assistant Examiner — Crescelle N. dela Torre 
Attorney, Agent, or Firm — Stoel Rives LLP 

[57] ABSTRACT 

A desktop manager application (20) manages graphical 
object creation, repositioning, resizing and related object 
placement functions in the context of a multi-monitor or 
other enhanced desktop environment. In a preferred 
implementation, the program manager (20) manages multi- 
pass window creation by allowing a graphical user interface 
operating system (16) to fill in a window structure in a 
hidden form and thereafter analyzing the window's coordi- 
nates relative to selected display criteria such as avoiding 
monitor splits. Based on this analysis, the program manager 
(20) selectively repositions the window under consideration 
in accordance with the display criteria. The program man- 
ager (20) thus provides a more user friendly interface 
between a GUI operating system (16) and applications in the 
enhanced desktop environment. 

14 Claims, 7 Drawing Sheets 



( START ) 
1 



MONITOR WINDOW 

MESSAGES N pb 



IDENTIFY & INTERCEPT ^ 
MESSAGE OF INTEREST N 30 



EXAMINE w 
PARAMETERS ^32 



^Rl 

v C e / DISPLAY x 
J^XCOORDINATES 
ACCEPTABI " 



TNO 



34 



ANALYZE MESSAGE WITH RESPECT 

TO CATALOGUED MULTIPASS ^ 36 
DRAWING PATTERNS 




ANALYZE FOR 
CONSISTENCY 
WITH RELATED 
MESSAGES 



| DELETE MESSAGE [ 



40 



CREATE DRAWING 
MESSAGE WITH 
REVISED COORDINATES 



^44 




04/04/2004, EAST Version: 1.4.1 



U.S. Patent 



Nov. 10, 1998 Sheet 1 of 7 



5,835 



15" 



16" 



APPLICATION 



FIG. 1 



DESKTOP 
MANAGER 



GUI 
OPERATING 
SYSTEM 



n 

18 



V 
20 



22 

i 
/ 

/ 

"""GRAPHICS' 
CARD 



GRAPHICS 
DRIVER 



24-T" 



GRAPHICS 
CHIP 1 



GRAPHICS 
CHIP 2 



26 



/ 



10 



I 



12- 



MONITOR 1 



MONITOR 2 



14 



04/04/2004, EAST Version: 1.4.1 



U.S. Patent 



Nov. 10, 1998 Sheet 2 of 7 



5,835, 



FIG. 2 



T 

MONITOR WINDOW 
MESSAGES 

T 



•28 



IDENTIFY & INTERCEPT 
MESSAGE OF INTEREST 

I 



30 



EXAMINE 
PARAMETERS 



'AR 

v _. DISPLAY . 
YIS^COORDINATES 
^ACCEPTABLE 

9 



34 



fNO 



ANALYZE MESSAGE WITH RESPECT 



TO CATALOGU 
DRAWING 



ED MULTIPASS 
PATTERNS 



■36 




DELETE MESSAGE 



I 



ANALYZE FOR 
CONSISTENCY 
WITH RELATED 
MESSAGES 



40 



CREATE DRAWING 
MESSAGE WITH 
REVISED COORDINATES 



I 



PASS MESSAGE BACK TO 
OS FOR PROCESSING 




44 



■46 



04/04/2004, EAST Version: 1.4.1 



U.S. Patent Nov. 10, 1998 Sheet 3 of 7 5,835,090 



( START ) 50 



MONITOR WINDOW 
MESSAGES 

I 



IDENTIFY DRAWING 
MESSAGES 



■52 



54 



IS 

DRAWING 

FOR WINDOW 

^COMPLETE. 
? 

fYES 



.NO 



56 
A- 



SET VISIBLE 
FLAG TO 
"OFF" 



58 



ALLOW 
WINDOWS TO 
DRAW 



ANALYZE COODINATES 
OF COMPLETED 
WINDOW 
RELATIVE TO 
DISPLAY CRITERIA 




DELETE 
UNACCEPTABLE 
COORDINATES 

7~ 
64 



SET VISIBLE 
FLAG TO "ON" 

\ 



CREATE DRAWING 
MESSAGE WITH 

REVISED 
COORDINATES 

7 

66 



DISPLAY WINDOW 



C END ) 



■70 



FIG. 3 



04/04/2004, EAST Version: 1.4.1 



U.S. Patent 



Nov. 10, 1998 



Sheet 4 of 7 



5,835,090 



FIG. 4 



( START ) 



72 



MONITOR USER 
ORIGINATED 
MESSAGES 



74 



IDENTIFY A MOUSE 
DOWN EVENT 




90 



IDENTIFY A 
KEYBOARD EVENT 



78 



MONITOR POSITION CHANGING 
MESSAGES DURING MOUSE 
DOWN EVENT 



92 

'DOES 
KEYBOARD 
EVENT HAVE AN 
ASSIGNED WINDOW 
REPOSITION 
FUNCTION 
? 

94 

TYES 2 



.NO 



YES. 



ARE 
DISPLAY 
COORDINATES 
ACCEPTABLE 

9 



NO 



LOOK UP REPOSITION 
INFO RMATION 



96 

I 



CREATE DRAWING MESSAGE 

IN ACCORDANCE WITH 
REPOSITION INFORMATION 



DELETE MESSAGE 
\ 



CREATE DRAWING MESSAGE 
WITH REVISED COODINATES 




YES 



88 



DISPLAY WINDOW 
( E ND ) 



04/04/2004, EAST Version: 1.4.1 



U.S. Patent Nov. lO, 1998 Sheet 5 of 7 



5,835,090 



O 
O 





o 

T— 

J 



00 

o 



□□□ 
□□□ 



00 



LO 
0 





CM 



J 



04/04/2004, EAST Version: 1.4.1 



U.S. Patent Nov. 10, 1998 Sheet 6 of 7 5,835,090 



FIG. 6 ( START ) 



112 



MONITOR 

WINDOWS 

MESSAGES 



r 



110 



IDENTIFY 
MINIMIZATION 
MESSAGE 



124 



IDENTIFY 
MAXIMIZATION 
MESSAGE 



-114 

HAS^ 
USER 
SELECTED 
MINIMIZATION 

.PREFERENCES. 
? 



-126 

'HAS^ 

USER 

SELECTED 

MAXIMIZATION 

PARAMETERS. 
? 



YES 



120 



116 



YES 



LOOK UP PREFERENCES 



MINIMIZE 
WINDOW 
ACCORDING 
TO DEFAULT 
PARAMETERS 



CREATE NEW 
DISPLAY MESSAGE 
ACCORDING TO 

USER 
PREFERENCES 



118 



128 



MAXIMIZE 
WINDOW 
ACCORDING 
TO DEFAULT 
PARAMETERS 



122 



DISPLAY WINDOW 



( END ) 



04/04/2004, EAST Version: 1.4.1 



U.S. Patent 



Nov. 10, 1998 



Sheet 7 of 7 



5,835,090 



FIG. 7 



IDENTIFY 

CLOSE 
MESSAGE 



132 



TRACE 
MESSAGE BACK 
TO APPLICATION 



SAVE STATE OF 
APPLICATION 

WINDOW 
IN REGISTRY 



( START ) 



MONITOR 

WINDOWS 

M ESSAGE S 



IDENTIFY 

OPEN 
MESSAGE 



130 



138 



DETERMINE 
APPLICATION 
INVOLVED 




-140 



NO 



YES 



144 



LOOK UP STATE 
OF SAVE WINDOW 
STATE 



148 



USE DEFAULT 

WINDOW 
PARAMETERS 



146 

1 



DISPLAY WINDOW 



( END ) 



04/04/2004, EAST Version: 1.4.1 



5,8: 

l 

DESKTOP MANAGER FOR GRAPHICAL 
USER INTERFACE BASED SYSTEM WITH 
ENHANCED DESKTOP 

This application is a continuation-in-part of application 
Ser. No. 08/732,179, filed Oct. 16, 1996, now abandoned. 

FIELD OF THE INVENTION 

The present invention relates generally to computer sys- 
tems employing a graphical user interface (GUI) operating 
system and, in particular, to a method for controlling the 
positioning of objects on the graphical desktop of such a 
system. The invention is particularly advantageous for use in 
enhanced desktop systems. 

BACKGROUND OF THE INVENTION 

A number of manufacturers are now offering GUI oper- 
ating systems. GUI operating systems employ graphical 
objects such as icons and windows (applications windows, 
child or document windows and dialog boxes) to prompt and 
receive user input. A user typically enters information by 
positioning a cursor within a designated area of the graphical 
desktop— e.g., by using a mouse, trackball, finger, stylus, 
direction keys or the like — to implement the desired func- 
tion. GUI operating systems have gained widespread accep- 
tance because of their simple, intuitive operation and 
because they allow for easy movement between multiple 
applications programs. 

Increasingly, consumers are demanding operating sys- 
tems with an enhanced desktop, i.e., an operating system 
working area larger than the display area of a single monitor. 
The enhanced desktop can be implemented by utilizing 
multiple monitors or by employing a virtual desktop area 
where the display area of a single monitor can be "scrolled" 
across a larger graphical desktop. Such enhanced desktop 
systems achieve greater display capability without the 
expense or inconvenience of a single, larger monitor. Users 
have demanded enhanced desktop systems in hope that they 
would be able to more fully exploit the abilities of improved 
processors and the multitasking efficiency of new operating 
systems. Additionally, enhanced desktop systems allow for 
improved display area as desired by certain professionals 
such as CAD and video editing professionals, financial 
professionals and professionals in the controls market where 
multiple system components and parameters may have to be 
simultaneously monitored. 

Unfortunately, conventional GUI operating systems are 
not specifically adapted for enhanced desktop operation. In 
fact, some newer GUI operating systems are designed to be 
highly hardware independent for increased compatibility. 
For example, such systems typically receive a drawing 
request from an application and translate the drawing 
request into standard drawing demands. The drawing 
demands are then passed directly to a graphics board device 
driver for execution. The driver translates the drawing 
commands into instructions for driving a graphics chip 
associated with a monitor. Some graphics drivers can drive 
multiple chips associated with multiple monitors. However, 
such multiple monitor drivers generally operate by simply 
mapping various areas of the operating desktop to particular 
monitors without regard to border effects such as window 
partition. Some attempts have been made to improve upon 
this situation by adding functionality intended to cause 
pop-up windows and dialogue boxes to appear on a single 
screen, but these systems have not provided fully satisfac- 
tory performance for a broad range of applications pro- 
grams. 
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SUMMARY OF THE INVENTION 

The present invention is directed to a method for use in 
controlling placement of graphical objects on a GUI oper- 

5 ating system desktop, especially in the enhanced desktop 
environment. The invention allows for better management 
of graphical objects on an enhanced desktop and reduces or 
eliminates a variety of user interface problems relating to 
monitor border effects. These objectives are substantially 

jo transparently achieved by operationally interposing a desk- 
top manager application between the operating system and 
the applications and having this desktop manager monitor 
(and modify) operating system requests. In this manner, a 
standard operating system API can be presented to the 

1S applications while controlling an enhanced desktop with 

respect to selected display criteria. The invention, which can 

be embodied in a software program or object code can 

operate in conjunction with a variety of operating system 

functions relating to object creation, movement, resizing and 

„„ the like. 
20 

According to one aspect of the present invention, graphi- 
cal object creation is controlled in the enhanced desktop 
environment relative to selected display criteria. For 
example, graphical object placement can be controlled to 

25 avoid monitor border problems or to position objects at user 
selected locations on the enhanced desktop. In the context of 
system or application originated graphical objects such as 
dialog boxes or pop-up windows, it is desirable to control 
creation of such objects so that they appear within the 

30 display area of a single monitor. It will be appreciated, for 
example, that a dialog box programmed to appear at the 
center of a desktop may be split in a dual or other multi- 
monitor system causing the text or other information to be 
difficult to read. Remedying this problem is complicated by 

35 the fact that certain objects of interest associated with certain 
applications are not drawn in a single pass but, rather, are 
created in a series of segments or steps. For example, an 
application may create a window by drawing in series the 
window frame, part of the body, another part of the body, etc. 
Similarly, an application may create a window at a first 
location and immediately move the window to a second 
location such that the window appears to be created at the 
second location to a user. These individual drawing opera- 
tions are separate but require consistent treatment. 

45 The desktop manager of the present invention addresses 
object creation including such multiple message processes 
so as to correctly relocate objects as desired on the enhanced 
desktop. The corresponding method of the present invention 
includes the steps of monitoring graphical object messages 

50 passing in the computer system and altering a selected 
display parameter of a first message relating to a given 
object. After the display parameter of the first message has 
been altered, the desktop manager analyzes the assigned 
coordinates of the graphical object and selectively changes 

55 the coordinates to reposition the object in accordance with 
selected display criteria. 

The method thus operates in at least two successive steps 
for a single graphical object to alter a first message and then 
analyze and selectively change the desktop coordinates of 

60 the object. This method can be implemented in various 
ways. In one implementation, the desktop manager is pro- 
grammed to recognize drawing patterns of multi-pass user 
interfaces, e.g., repeated sequences for drawing window 
elements and/or compound draw-and-move window cre- 

65 ation. These patterns can be deduced empirically by observ- 
ing operation of particular application functions. Based on 
the recognized patterns, such multi-pass processes can be 
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bandied in a coordinated way to correctly reposition the 
object involved. For example, each element of the window 
can be repositioned (by analyzing and selectively altering a 
display parameter relating to desktop coordinates) as it is 
drawn in a manner such that the completed elements form an 5 
integrated and correct window. 

More preferably, the desktop manager alters a display 
parameter (e.g., the visible flag) of object messages to 
prevent display of the object until drawing is completed. In 
this regard, it has been recognized that the multiple element l0 
object creation processes commonly conclude with one of 
various messages such as a SHOWW1NDOW or WIN- 
DO WPOSCHANGING message. When a final message is 
received, the desktop manager then analyzes the object 
coordinates relative to the selected criteria such as avoiding ]5 
border errors. If the position of the object is acceptable, the 
state of the display is changed from invisible to visible and 
the object is displayed. If the position is not acceptable, the 
object coordinates are modified in accordance with the 
selected display criteria. This implementation eliminates the 2 o 
need for pattern recognition and reduces changes to external 
information. Moreover, the method increases compatibility 
with existing and new applications programs. 

In the context of user originated object creation messages, 
the desktop manager preferably allows the user to determine 2 5 
whether to employ controls as described above. For 
example, the user may select a "Single Monitor Windows" 
function to avoid monitor splits. In such cases, the desktop 
manager will control user originated window creation mes- 
sages according to either of the implementations discussed 30 
above. It will be appreciated, however, that the user may 
desire to deactivate the "Single Monitor Windows" function 
to allow multi-monitor window displays, e.g., display across 
the entire enhanced desktop. The desktop manager can also 
be programmed to control placement of secondary objects 35 
(i.e., objects created within other objects) such as child or 
document windows as well as parent or primary objects. 

Object relocation can be conducted relative to a variety of 
display criteria. Procedurally, the desktop manager relocates 
the object either by deleting the original message(s) and 40 
creating a new message with different coordinates for draw- 
ing the object or by modifying the parameters of the original ■ 
message. These new coordinates can be selected to relocate, 
for example, to a particular monitor of a multi-monitor 
system, to the closest monitor as determined by which 45 
monitor contains the greatest area of the object, to the 
current position of the cursor or, in the case of a secondary 
object such as a child window, to the monitor of the closest 
parent or primary object. In the case of user originated 
objects, the desktop manager can also implement a storing 50 
feature to reopen an object at the same location occupied 
when the object was previously closed. It will be appreciated 
that other display criteria can be employed. 

According to another aspect of the present invention, 
graphical object movement is controlled relative to selected 55 
display criteria based on user originated messages. The user 
originated messages are entered, for example, via a cursor 
device such as a mouse, trackball, finger or stylus, or via a 
keyboard. In the case of cursor input, the corresponding 
method of the present invention includes the steps of: 60 
monitoring cursor events to identify a first message relating 
to initiation of object repositioning; identifying the object 
which is the subject of the first message; tracking subsequent 
messages associated with the identified object to identify a 
second message relating to object repositioning; analyzing 65 
display coordinates of the object in response to the second 
message; and selectively relocating the object based on 
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selected display criteria. By way of example, for drag and 
drop window repositioning, the step of monitoring cursor 
events may involve intercepting a mouse down message 
event and determining whether the event occurred when the 
cursor was positioned on a window title bar, thereby indi- 
cating that repositioning has been initiated. Subsequent 
drawing messages can be tracked while the mouse button is 
down by using a window booking (WH) function. For each 
message or in response to a final message (e.g., a mouse up 
message), the drawing coordinates for the object can be 
analyzed relative to selected criteria such as avoiding moni- 
tor splits. When relocation is required, new coordinates can 
be designated relative to the design criteria, for example, to 
relocate the object on the closest monitor. 

It has also been found useful in the enhanced desktop 
environment to allow for object repositioning based on 
keyboard input. The corresponding method includes the 
steps of: assigning an object relocation function to a key- 
board input (key stroke or series of strokes); monitoring 
keyboard events to identify an occurrence of the keyboard 
input having the assigned function; and, in response to the 
occurrence of the keyboard event, relocating an object from 
a first position outside of a display area of a monitor to a 
second position inside the display area. In this manner, 
various keyboard inputs can be programmed to function as 
"hotkeys" for convenient object relocation in the enhanced 
desktop environment. 

The desktop manager of the present invention also 
includes a convenient graphical interface for repositioning 
objects relative to the enhanced desktop and for keeping 
track of object positions. In a multi-monitor system where 
many applications may be running on the various monitors, 
it has been found useful for the user to be able to determine 
from a quick glance at a single monitor where particular 
applications reside. Moreover, it is desirable to effect move- 
ment of an object across monitor borders without undue 
scrolling or the like. Accordingly, the desktop manager of 
the present invention implements a "bird's eye view" func- 
tion by providing a graphical representation of the enhanced 
desktop within the display area of a single monitor; provid- 
ing a graphical symbol for each object resident on the 
enhanced desktop; and positioning each such graphical 
symbol at a symbol location within the graphical represen- 
tation of the enhanced desktop that reflects the object 
location of the corresponding object on the enhanced desk- 
top. The desktop manager further allows for movement of 
objects relative to the enhanced desktop by moving the 
symbol relative to the graphical representation, e.g., by 
dragging and dropping the symbol. 

According to a further aspect of the present invention, the 
desktop manager allows for object resizing or state changes 
including minimization in the enhanced desktop environ- 
ment. The corresponding method of the present invention 
includes the steps of: monitoring object messages to identify 
a message relating to object minimization; identifying 
selected positioning criteria relating to object minimization, 
where the selected criteria allow for minimization position- 
ing independent of default minimization parameters; and 
selectively repositioning the minimized object in accordance 
with the selected display criteria. Preferably, the desktop 
manager allows the user to select the display criteria from 
various options such as relocating to a particular monitor of 
a multi-monitor system, relocating to the current cursor 
position and, in the case of secondary objects, relocating to 
the closest parent or primary object monitor. 

Relatedly, the desktop manager also allows for selective 
object maximization in a preferred implementation. In this 
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regard, the desktop manager monitors object messages to 
identify a message relating to maximization; identifies the 
assigned coordinates of the maximized object based in the 
identified message; analyzes the coordinates of the maxi- 
mized object; and selectively repositions the maximized 
object relative to the selected display criteria. Preferably, the 
user can select from various maximization options including 
maximizing to the full desktop; to a single monitor of a 
multi-monitor system or to the monitors) containing the 
corners of the object. 

The desktop manager system of the present invention thus 
provides a substantially invisible interface between a GUI 
operating system and applications that allows the potential 
benefits of enhanced desktop systems to be more fully 
realized. System or application originated object creation, as 
well as user originated object creation, is managed with 
respect to desired display criteria so as to facilely handle a 
broad range of object creation functions including multi- 
pass drawing. The desktop manager also provides and 
manages a range of object repositioning, resizing, tracking 
and state change functions for increased efficiency in the 
enhanced desktop environment. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present inven- 
tion and further advantages thereof, reference is now made 
to the following detailed description taken in conjunction 
with the drawings, in which: 

FIG. 1 is a schematic diagram of a multimonitor computer 
system operated in accordance with the present invention; 

FIG. 2 is a flow diagram illustrating a window creation 
process implemented by the desktop manager of the present 
invention; 

FIG. 3 is a flow diagram illustrating an alternative win- 
dow creation process implemented by the desktop manager 
of the present invention; 

FIG. 4 is a flow diagram illustrating processes for repo- 
sitioning windows in response to user originated messages 
as implemented by the desktop manager of the present 
invention; 

FIG. 5 is a schematic diagram illustrating operation of the 
bird's-eye view function as implemented by the desktop 
manager of the present invention; 

FIG. 6 is a flow diagram illustrating processing of mini- 
mization and maximization messages by the desktop man- 
ager of the present invention; and 

FIG. 7 is a flow diagram illustrating operation of the 
windows state saving function as implemented by the desk- 
top manager of the present invention. 

DETAILED DESCRIPTION OF THE 
INVENTION 

The present invention is directed to managing placement 
of graphical objects in a computer system including a GUI 
operating system and is particularly beneficial for systems 
including an enhanced desktop. In the following description, 
the invention is set forth in the context of the WINDOWS 95 
or WINDOWS NT operating systems marketed by 
Microsoft Corporation of Redmond, Wash. It will be 
appreciated, however, that the various operating system 
attributes employed by the desktop manager of the present 
invention have counterparts in other GUI operating systems 
including Win31, Xwindows, System 7, OS/2 and others, by 
way of example, the operating system messages, windows 
and message synchronization discussed below are used by 
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all known GUI operating system on the market today in 
substantially the same way. Particular messages (e.g., 
SHOWWINDOW, CREATE and MOVEWINDOW) and 
data parameters (e.g., visibility, screen coordinates, etc.) 

5 referenced below are specific to Microsoft Corporation 
products including WINDOWS NT, 95 and 3.11, but other 
systems including Xwindows, System 7 and OS/2 have 
equivalent functions. Similarly, certain Application Pro- 
gramming Interface (API) calls referenced below such as 

10 SetWindowsHcokEx and GetWindowRect are specific to 
Windows NT, 95 and 3.11 although other systems including 
Xwindows, System 7 and OS/2 have equivalent functions. 
Accordingly, it will be appreciated that the specific imple- 
mentations of the present invention set forth below are 

15 exemplary and the present invention is not limited to the 
specifically described functions or operating environment. 

SYSTEM ARCHITECTURE 

FIG. 1 shows a schematic diagram of a multi-monitor 

2 0 computer system 10 in accordance with the present inven- 
tion. Although more monitors may be employed in accor- 
dance with the present invention, the illustrated system 10 
includes two monitors 12 and 14. The system further 
includes: a GUI operating system 16; a graphics driver 

25 application 18 and a desktop manager application 20 (which 
may be combined into a single application) embodied in the 
computer system 10; and graphics chips 24 and 26 (which 
may also be embodied in the graphics card(s) 22) for 
operating the respective monitors 12 and 14. It will be 

30 appreciated that the computer system includes additional 
conventional elements that are not shown such as a central 
processing unit (CPU), input/output (I/O) busses, static and 
dynamic memory, etc. 
The operating system 16 can be any of various GUI or 

35 windows-based operating systems as noted above. For the 
purposes of the present description, the operating system 16 
is taken to be WINDOWS NT or 95 marketed by Microsoft 
Corporation of Redmond, Wash. Generally, the operating 
system 16 receives drawing instructions from a compatible 

40 applications program and directs the graphics driver 18 to 
draw on the graphical desktop. WINDOWS NT and 95 
separate the applications programs from specific hardware. 
The operating system 16 can thus interface any WINDOWS 
compatible applications program with any suitable monitor, 

45 provided the monitor is driven by a windows compatible 
driver. In this regard, graphics drivers conventionally pro- 
vide information to the operating system regarding the size 
of the desktop on which the operating system may work. 
When the operating system receives a drawing request, it 

50 translates the request into a standard set of drawing com- 
mands based on the desktop size information and passes the 
commands to the graphics driver for execution. The graphics 
driver, in turn, translates the commands from the operating 
system into drawing commands that a graphics chip can 

55 recognize. 

This independence of the operating system and the dis- 
play hardware allows for greater hardware compatibility, but 
does not provide a mechanism whereby the operating system 
can distinguish between a single, continuous desktop coex- 

60 tensive with the monitor display area (screen) and an 
enhanced desktop. The illustrated desktop manager 20 is 
operationally interposed between the operating system 16 
and the applications 15 to provide various functions, as set 
forth in detail below, for managing graphical object display 

65 in the enhanced desktop environment. The desktop manager 
20 monitors and modifies, as set forth in detail below, 
messages which pass between the applications and the 
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operating system. The graphics driver 18 presents a standard display coordinates are acceptable e.g., whether the subject 
graphics device driver interface to the operating system 16 window or window segment crosses a monitor border. If the 
while controlling multiple graphics chips 24 and 26 to create assigned coordinates are acceptable, the desktop manager 
a multi-monitor, enhanced desktop. The graphics driver releases the message and the window or segment is dis- 
program 18 implements conventional driver functions for 5 played (48). If the coordinates are not acceptable, the 
translating standard WINDOWS operating system com- desktop manager analyzes (36) the message to determine 
mands into graphics chip commands. It will thus be appre- whether the message may be part of a multi-pass drawing 
ciated that the illustrated desktop manager 20 is fully operation. It is important that all parts of a multi-pass 
compatible with WINDOWS NT and 95. Moreover, any drawing operation be handled consistently so that the win- 
compatible graphics chips 24 and 26 can be employed in 10 dow can correctly formed. Unfortunately, the patterns of 
conjunction with the system 10. The illustrated chips 24 and such multi-pass operations are not prescribed by convention 
26 may be, for example, a GD5434 chip manufactured by and vary from application-to-application as determined by 
Cirrus Logic. Any compatible graphics driver logic may be programmers. Consequently, such patterns are deduced 
employed. empirically for specific applications in the illustrated pro- 

In order to implement the full range of functions 15 cess * 0noe a ? atlem * ^ catalogued, it is stored in 

described below, the desktop manager employs several memory. Individual messages and sequences of messages 

system-wide windows message hooks. These include can lnen be compared to the stored patterns to determine 

WH_GETMESSAGE, WH_CALLMESSAGE, whether the message matches (38) a catalogued pattern. 

WH_MOUSE, and WH_CBT. These hooks allow desktop When a match is found, the pattern can be used to analyze 

manager 20 to monitor and modify windows messages. They 20 0*°) me message for consistency with related messages in 

provide a filtering function whereby the operating system 16 the multi-pass pattern. That is, if a previous related message 

executes the filter function before processing an event. has been repositioned to particular display coordinates, the 

Hooking applications are well known and the process for subject message can be consistently repositioned, 

installing hooks is set forth in many publications available Technically, the window or segment is repositioned by 

from Microsoft Press. The hooks employed by the desktop 25 deleting (42) the original message and creating a new 

manager 20 monitor messages from all processes/threads message with coordinates selected according to specified 

associated with the operating system 16 and are therefore display criteria. Such criteria can be selected by the user. The 

preferably located in a dynamic link library. desktop manager of the present invention allows for repo- 

The discussion below refers to a number of functions sitioning in the case of a monitor split to any of at least: a 

performed by the desktop manager 20 relating to graphical 30 particular monitor selected by the user (e.g., in case of 

object creation, moving, resizing and the like. It will be monitor splits, the window will be repositioned to monitor 

appreciated that such functions can be implemented in *)» t0 the closest monitor (determined by which monitor 

various ways. In this regard, the functions can be compiled includes the greatest area of the assigned display 

and run in computer system 10 as object code (software). In coordinates), to the current position of the cursor, or, in the 

the illustrated embodiment, the desktop manager 20 is 35 case of secondary objects such as child windows, to the 

embodied in software for installation into computer system monitor where the closest parent application resides. The 

10 closest parent application is found by tracing messages back 

to the parent application. Once the new message has been 

Object Creation created, it is released and the window or segment is dis- 

FIGS. 2-3 illustrate processes for controlling dialogue 40 played (46). If the drawing is not complete (48), the desktop 

box or pop-up window creation in accordance with selected manager continues to monitor window messages (28) and 

display criteria. In particular, the processes of FIGS. 2-3 are the process is repeated. 

capable of handling multi-pass window creation as well as Referring to FIG. 3, an alternative process for handling 

single step window creation, and address the objective of window creation operations including multi-pass operations 

avoiding monitor splits. FIG. 2 involves a drawing pattern 45 is shown. The process does not rely on pattern recognition 

recognition approach for consistently handling the various and is therefore more broadly applicable. Moreover, as 

elements of a multi-pass drawing operation. FIG. 3 involves empirical pattern recognition is not required, the process can 

a process of allowing a window to be completed in hidden operate on new applications for which no empirical pattern 

form and then repositioning the completed window as information is available. Additionally, the code required for 

necessary prior to visible display. Although these processes 50 implementing the process of FIG. 3 is less cumbersome and 

are set forth with respect to handling application or system can be executed more quickly because comparison to mul- 

originated objects such as dialogue boxes or pop-up win- tiple patterns is not required. 

dows. Similar processes can be employed with respect to The process is initiated by monitoring (50) window 

user originated objects. messages to identify (52) drawing messages of interest as 

Referring to FIG. 2, the illustrated process is initiated by 55 described above in connection with FIG. 2, i.e., by employ- 
monitoring (28) window messages to identify (30) messages ing a message hooking function to identify CREATE or 
of interest. In the WINDOWS operating system protocol, SHOWWINDOW messages. Upon identifying a message of 
when a window is created, a "CREATE" type message is interest, the desktop manager first analyzes the message 
sent from the operating system to the application represented parameters (e.g., WindowStyle) to determine if the param- 
by the window. The desktop manager intercepts these "CRE- 60 eters are consistent with the type(s) of windows that the 
ATE" type messages by calling the SetWmdowsHookEx manager is programmed to control. The desktop manager of 
API. This causes the desktop manager to hook all such the present invention allows for control of various window 
messages passing in the system. This hooking function types including parent windows and child windows. If the 
allows the messages to be analyzed and modified as neces- window is of a type managed by the desktop manager, rather 
sary prior to execution. 65 than changing the coordinates at each pass of a multi-pass 

Upon intercepting a message, the message parameters are operation, the desktop manager sets (56) a visible flag to 

examined (32) to determine (34) whether the assigned "off* and allows (58) the operating system to draw at the 
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assigned coordinates during window creation. This involves how the desktop manager identifies particular classes of 
clearing a visibility flag included in the windows param- windows to be hooked and gives a window a "hidden" style 
eters. The sample code sections set forth in Table 1 illustrate during drawing: 



TABLE 1 



//•••" ••• * 

// 

// PlacementControl:WM_CREATE 
// 

//"•""*" 

case WM_CREATE: 
{ 

LPCREATESTRUCT Ipcs; 
Ipcs = (LPCREATESTRUCT) pcwps->lParam; 
if((GtlParcnl(pcwps->hwod) — NULL)&& 
(gbooklnfo.hwndParenl — NULL)) 

{ 

LPCTSTR string 
int i; 
// 

// RELEASE POP-UP WINDOWS 

// 

if(lpcs->style & WS_POPUP) 
break; 

} 

// 

//RELEASE -PROXY TARGET" WINDOWS WHICH ARE CREATED JUST 
//BEFORE "MY COMPUTER" TYPE WINDOWS... 

// 

if((]pcs->ac 0)&& 

(lpcs->cy — 0)&& 
(lpcs->x — 0)&& 
(lpcs->y — 0)&& 
(lpcs->style ~ 0)&& 
(lpcs-xlwExStyle ~ 0)) 

{ 

ghooklnfo.hwndParent - NULL; 
break; 

} 

// 

//GET HANDLE OF PARENT WINDOW THAT'S BEING CREATED 

// 

ghooklnfo.hwndParent - pcwps->hwnd; 

// 

//WINDOW POSITION MEMORY INFO 

// 

if(Getaassl^ng(Dcwps->hwnd, GCW _ATOM) !- (ULONG)lpcs->lpszClass) 
{ 

//GET THE CLASS NAME OF THE WINDOW THAT IS BEING 

//CREATED 

// 

string - lpcs->lpszClass; 
// 

//SPECIAL CASES... 

// 

if((strcmp(string, M ML__ReadNote") — 0)|| 

(strcmp(string, "ML_SendNote") ~ 0)) 

{ 

ghooklnfo.hwndParent = NULL; 
break; 

} 

for(i-0;i<10;i++) 
{ 

if(sLranp(string,awpWindowPosition[i} Class Name) — 0) 

// 

// 

//GIVE THE WINDOW A "HIDDEN" STYLE FOR NOW 

// 

lpcs->style |- WS_VISIBLE 
lpcs->style A - WS_VISIBLE; 

} 

if((GetParcnt(pcwps->hwnd) !- NULL)&& 
(lpcs->style & WS_POPUP)) 

{ 

if (! ghooklnfo.bDialog) 

{ 
// 
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TABLE 1 -continued 



// SAVE HANDLE FOR POPUP WINDOW 

tl 

gbook!nfo.hwndPopup - pcwps->hwnd; 
if(lpcs->style & WS_DLG FRAME) 
{ 

ghookInfo.bDialog - TRUE; 

} 

if(GetaassLong(pcwps->hwnd, GCW_ J ATOM) !- (ULONG)lpcs->lpszaass) 
{ 

LPCTSTR string; 
string - lpcs->lpszClass; 
// 

// THESE WINDOW CLASSES SHOULD NOT BE HOOKED... 
// 

if((strcmp(string > TipHelp") — 0)|| 

(strcmp(string, "MSINToolTip") — 0)) 

{ 

ghooklnfo.hwndPopup - NULL; 
ghooklnfo.bDialog - FALSE; 

} 

} 

if(lpcs-xiwExStylc & WS_EX_TOOLWINDOW) 
{ 

ghooklnfo.hwndPopup - NULL; 
ghooklnfo.bDialog - FALSE; 



The window is then "drawn" by the operating system as 
it normally would but will not be visible in the display area 
of the monitor due to the clearing of the visible flag. In this 
regard, each window has a data structure that describes the 
display parameters of the window including its size, 
coordinates, etc. The desktop manager allows this structure 
to be filled in completely, but prevents the window infor- 
mation from being displayed. 

The desktop manager continues to monitor window mes- 
sages to determine (54) when the window is completed. It 
has been recognized that window creation including multi- 
pass creation operations consistently conclude with a 
SHOWWINDOW or WINDOWPOSCHANGING message. 
Upon receiving one of these messages, the desktop manager 
analyzes (60) coordinates of the completed window to 
determine (62) whether the coordinates are acceptable. This 
is accomplished by querying the window using the GetWin- 
dowRect function which returns the coordinates. This infor- 
mation is compared to previously entered display criteria as 
described above, e.g., to determine whether the window 
crosses a monitor border. 



If the coordinates are acceptable, the visible flag is reset 
(68) and the window is displayed (70). The display is 
initiated using standard procedures by issuing a SHOW- 
WINDOW message. If the coordinates are not acceptable, 
the desktop manager alters the windows data structure to 
provide new coordinates, relating to size and position, in 
accordance with the selected display criteria (e.g., relocate to 
a particular monitor, to the closed monitor to the cursor, or 
to the monitor of the closest parent application). This 
"redrawing" can be implemented by sending a MOVEWIN- 
DOW message to the window so as to delete (64) of the 
unacceptable coordinates and create (66) drawing messages 
with revised coordinates. It should be noted that the window 
is still invisible and the operating system may still be 
drawing at this point. The window is then made visible and 
displayed as described above. 

The code sections set forth in Table 2 illustrate how the 
desktop manager repositions windows: 



30 



35 



40 



TABLE 2 



PlacementControl:WM„SHOWW[NDOW 



case WM_SHOWWlNDOW: 
showwindow: 
{ 

HWND hwndTcmp; 

tnt y, width, height; 

RECT rcct; 

ROW_OOLUMN monitorTopLeft; 
POINT pt; 
if ((ghooklnfo.hwndPopup — pcwps->hwnd)&& 
(ghooklnfo.bDialog — TRUE)) 

{ 

// 

//GIVE THIS SHOWWINDOW MESSAGE A HIDDEN STYLE 

// 

pcwps->wPaiam - FALSE; 
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TABLE 2 -continued 



// MONITOR 



hwmfftmp - ghooklnfo.hwndPopup; 
ghooklnfo.hwndPopup * NULL; 
ghookInfo.bDialog - FALSE; 
GetWindowRcct(hwndTemp,&rcct); 
x - red, left; 
y - red. lop; 

width - rccL right - recLleft; 
height - recLbottom - recuop; 
if((ghoold*egi£lry.Desktop.pc6it^ 
(! gSuspendDialog)) 



{ 



switch (ghookRegistry.Desktop.position^ 



{ 



GctWLndowRect(hwndParentApp,&ParenlR«ct); 
ParentRect.top)/2; 



case CONTROL_DIALOG_POS_PARENT_APP: 
{ 

// 

// SHOW DIALOG ON (PARENT) APPLICATION'S 

// 

HWND hwndParentApp; 

RECT ParcntRcct; 

hwndParentApp - GetParent(hwndTemp); 

if( hwndParentApp I- NULL) 

{ 

// 

//DIALOG MUST HAVE PARENT APPLICATION 

// 

x - ParentRectleft + (ParentRectright - ParentRect,left)/2; 

y - ParentRecttop + (Pa re ntRect. bottom - 



RESIDES 



monitorTopLeft column)>x)[| 
(monitorTopLeft column + l))<(x + width)|| 
monitoiTopLeft row)>y)|| 
(monitorTopLeft row + l))<(y + height)) 



} 

break; 

{ 

case CONTROL_DIALOG_POS_ACnVE_CURSOR: 
{ 



SHOW DIALOG ON MONITOR WHERE CURSOR 



//Get Mouse Cursor Position 
// 

GetCursorPosC&pt); 

monitorTopLeft - GetMonitorLocation(pt); 
// 

//Dialog is outside of cursor's monitor - reposition 
// 

if( ((int)(ghookRegistry.Monitor.XReso)ution * 
((int)(ghookRegistry.MonitorJUlesolution * 
((int)(ghookRegistry.Monitor.YResolution " 
((int)(ghookRegistry.Monitor.YResolution * 



DIALOG 



monitorTopLeft column) > x)|J 
(monitorTopLeft column + l))<(x + width))|| 



} 

break; 



■pt x; 
• pty; 



} 

case (X»NmOL_DIAlX)G_POS_CLOSEST_MONITOR: 

{ 

// 

// SHOW DIALOG ON MONITOR CLOSEST TO MIDPOINT OF 

// 

pt x = rectleft + (recUight - rect!eft)/2; 
pty - recttop + (rectbottom - rcct.top)/2; 
monitorTopLeft - GetMonitorLocation(pt); 
// 

//Dialog is outside of monitor - reposition 

// 

if( ((mt)(ghookRegistry.Monitor.XResoluiion * 
((int)(ghookRegistry.MonitonXResolution * 
(fint)(ghookRegistry.Moaitor.YResolution • 
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TABLE 2-continued 



monitorTopLeft row) > y)|| 
(monitorTopLcfi row + l))<y + height)) 



((int)(ghookRegi$try.Monitor.YRtsolution • 



{ 



x-ptx; 
y-pt y; 

} 

break; 

} 

default: 

{ 

II 

//SHOW DIALOG ON MONITOR #X 

// 

DWORD monitor! ndex; 
monitorlndex - 



ghcK>kRegi5try.Desklop.positionC^mrol.DialogPosLtion - 
CONTROL_DlAljOG_POS_MONnDR_NUM; 



monitoilndex; 



monitorlndex - 2; 



if(ghookRegLStry.Monitor.NRows > 1) 
i£CghooxRegistry.Monitor.NColumns > 1) 
{ 

// 

//SQUARE CONFIGURATION 



// 



if(monitorlndex < 2) 

< 

monitorTopLeft column « 



} 

else 

{ 



> 



monitorTopLeft row - 0; 

monitorTopLeft column » 
monitorTopLeft row - 1; 



} 

else 

} 

// 

//TALL CONFIGURATION 

II 

} 



monitorTopLeft column - 0; 
monitorTopLeft row - monitorlndex; 



> 



} 

else 

{ 

// 

//WIDE CONFIGURATION 

// 

monitorTopLeft column - monitorlndex; 
monitorTopLeft row - 0; 

} 

x - (gh ook Re gistr y. Mo ni to r.X Re solution * monitorTopLeft column) 

(ghookRegistry.Monitor.XResolulion/2); 
y - (gh oo k Re gis tr y. Mo nitor.YRe solution * monitorTopLeft row) + 
(ghookRegistry. Monitor. YResolution/2); 

break; 



> 

red - SingleMonitorDialog(x, y, width, height); 
x - recUeft; 
y - rect.top; 

width - reel, right - recUeft; 
height - rect bottom - rect. top; 

} 

// 

//MOVE THE WINDOW TO WHERE WE WANT IT AND MAKE IT VISIBLE 

// 

MoveWindow(hwndTemp, 
x, 

y. 

width, 
height, 
TRUE); 
ShowWindow(hwndTemp, 

SW_SHOW); 
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TABLE 2 -continued 



Update Window(hwttdTcmp); 

} 

if(pcwps->hwnd ™ ghooklnfo.hwndParcnt) 

// 

//GIVE THIS SHOWWINDOW MESSAGE A HIDDEN STYLE 

// 

pcwps->wParam - FALSE; 
hwndTemp - ghooklnfo.hwndParcnt; 
ghooklnfo.hwnd Parent «■ NULL; 
GetWindowRcct^hwndTcrrrp, &rcct); 
if(( ghookInfo.bPositionMemory)&& 

(ghookRcgistjy.Dcsktop.positionControl.PosiUonMcmory)) 

{ 

// 

//MOVE THE WINDOW TO WHERE WE WANT IT AND MAKE IT VISIBLE 

// 

Move Wind ow(hwrtdTemp, 

y> 

width, 

height, 

TRUE); 
S ho wWindo w(h wndTe mp, 

SW_SHOW); 
Update Window(hwndTemp); 

} 

return FALSE; 

} 



Object Repositioning 

FIGS. 4-5 illustrate various processes implemented by 30 
the desktop manager for repositioning windows in response 
to user originated messages. Referring to FIG. 4, a process 
for repositioning windows in response to cursor device 
events, e.g., mouse events, will first be described. The 
process is initiated by monitoring (72) user originated mes- 35 
sages to identify (74) a mouse down event of interest, e.g., 
a WM_NCLBUTTONDOWN message in response to 
depressing a mouse button. Such messages can be monitored 
by installing an appropriate hooking function. Upon hooking 
such a message, the "hit test code" of the message is 40 
analyzed to determine (76) whether the left move button is 
down and whether the mouse cursor is located in the title bar 
of a non-child (primary) window. If so, the desktop manager 
recognizes that the window is being dragged, records the 
window's handle and continues to monitor (76) movement 45 
of the window. Otherwise, the mouse event is not deemed a 
dragging event, the associated message is released and the 
desktop manager continues to monitor (72) user originated 
messages. 



When a dragging event is recognized, the desktop man- 
ager monitors all WIND OWPOS CHANGING messages for 
the window until receiving (86) a WM_LBUTTONUP 
message indicated that the left mouse button has been 
released and the dragging operation is complete. The desk- 
top manager analyzes these messages throughout the drag- 
ging process to determine (80) whether the window coor- 
dinates are acceptable, e.g., to prevent monitor splits. If the 
WIND OWPOS structure corresponding to any of these 
messages indicates that the window is being dragged across 
a monitor border, the desktop manager will revise the 
window coordinates by deleting (82) the original message 
and creating (84) a drawing message with revised coordi- 
nates as described above. For example, a closest monitor 
repositioning function may be applied to all such messages 
during an interval of the dragging operation where the 
window would be dragged across a border. The result would 
thus be that the window, as displayed (88), would snap 
instantaneously across the monitor split. 

The sample code sections set forth in Table 3 illustrate 
how the desktop manager manages drag and drop window 
moving operations: 

TABLE 3 



// 

// IF "SINGLE MONITOR WINDOWS" IS SELECTED, DONT LET THE WINDOW CROSS 

MONITOR BOARDERS 

// 

if (ghookRegistry.Desktop.Single Window) 
{ 

unsigned int i; 

for(i«l;i<ghookRegistry.Monitor.NColuinns; i++) 
{ 

int boarder; 

boarder - (ghookRegistry.Monitor.XResolution *i); 
if(((x + width) >boarder)&& 
(x < boarder)) 

{ 

if( ((x + width)-boarder)<(boarder - x)) 
{ 

if (width > (int)ghookRegistry.Monkor.XResolution) 
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TABLE 3-continued 



{ 

width - ghookRegistiy.Momtor.XKesolution; 

} 

x - boarder - width; 

} 

else 

{ 

x - boarder; 

if(width > (int)ghookRegistry.MonitorJCResolution) 
{ 

width - ghookRcgistry. M on itor.XRc solution; 

} 

} 

} 

} 

for(i-l;i < ghookRegistry.Momtor.Wlows;i++) 
{ 

int boarder, 

boarder - (ghootRcgistry.Monitor.YResolution *i); 
if(((y + height) > boarder)&& 
(y < boarder)) 

{ 

if( (Cy + height) - boarder) <(boarder - y)) 

if(height > (int)ghookRegistry.Moaitor.YResolution) 
{ 

height - 

ghookRegistry.Monitor.YResolution; 

} 

y - boarder - height; 

} 

else 
{ 

y - boarder; 

if(height > (int)ghookRegistry.Monitor.YRcsolution) 
{ 

height ■ 

ghookRegistry.Monitor.YResolution; 

} 

} 

} 

} 

} 



FIG . 4 also illustrates a process for repositioning windows 40 
in response to keyboard events, e.g., key strokes or series of 
strokes programmed to have a selected window reposition- 
ing function ("hot keys"). For example, a particular key can 
be assigned the function of moving the active window to a 
particular monitor, e.g. monitor 1. The process is initiated by 
monitoring (72) user originated messages to identify (90) a 45 
keyboard event having an assigned function. Again, this can 
be implemented using an appropriate hooking function. 
When the desktop manager determines (92) that the key- 
board event has an assigned function, it looks up (94) the 
associated function parameters (reposition information) and 50 
creates (96) a drawing reposition message reflecting the new 
coordinates specified by the hot key function. This is tech- 
nically implemented by querying the window to determine 
what application is active, recording the associated window 
handle, deleting the keyboard message and issuing a 55 
MOVEWINDOW message. The MOVEWINDOW message 
is then executed and the window is displayed (88) at the 
coordinates dictated by the hot key function. 

FIG. 5 schematically illustrates a bird's eye view function 
of the desktop manager for indicating the positions of 60 
windows or other objects on the desktop. The system 97 of 
FIG. 5 includes, for example, four monitors 98-104, As 
shown, each of the monitors 98-104 may have one or more 
windows currently open and resident in its display area. In 
the illustrated embodiment, the bird's eye view function of 65 
the desktop manager is represented by a window 106 that is 
contained with the display area 108 of monitor 98. As 



shown, the window 106 displays a graphical representation 
of the enhanced desktop which includes the respective 
display areas of the monitors 98-104. The bird's eye view 
thus provides a convenient way for the user to recall where 
various applications are positioned at a glance. 

The bird's eye view function also allows for convenient 
repositioning using a drop and drag procedure. In particular, 
the user can click on a representation, in the bird's eye view 
display, of the actual window, drag the representation rela- 
tive to the bird's eye view display and then release the 
mouse button. The associated window will be moved in 
corresponding fashion across the enhanced desktop. This is 
implemented by monitoring mouse down events using a 
hooking function to identify events occurring when the 
mouse cursor is located on a particular window representa- 
tion within the bird's eye view display. The associated 
window handle is then recorded and the event is treated as 
if the actual window was being dragged (see window 
repositioning discussion above). When the mouse up mes- 
sage (WM_LBUTTONUP) is received or, optionally, con- 
tinually during the dragging operation, the desktop manager 
translates the new position of the window representation as 
the bird's eye view display into a corresponding new win- 
dow position on the enhanced desktop and issues an appro- 
priate MOVEWINDOW message. 

Object Resizing 

FIG. 6 illustrates processes implemented by the desktop 
manager for minimizing and maximizing windows in the 
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enhanced desktop environment. The minimization process is nates of the preferred maximization parameters and the 
initiated by monitoring (110) WINDOW MESSAGES to maximized window is displayed (122). If no preferences are 
identify (112) a minimization message. Similar to the dialog provided by the user, the window is maximized (128) 
reposition process discussed above, this is accomplished by according to default maximization parameters defined by the 
using a hooking function SetWindowsHookEx API to catch 5 operating system or application (typically to the full 
the windows minimize message. When a minimization mes- desktop) and the maximized window is displayed (122). 
sage is thus received, the desktop manager determines (114) Application Memory 
whether the user has previously selected any minimization Referring to FIG. 7, the desktop manager also implements 
preferences. In the enhanced desktop environment, minimi- an application memory fo QClion that stores window infor- 
zation is often problematic in that the resulting minimized 10 mat ion when an application is closed so that the window can 
window or icon may appear on a different monitor and be subsequently be opened in the same state, e.g., in the same 
difficult to find or inconvenient to access. The desktop position and with the same dimensions. The process is 
manager allows the user to select from various minimization initiated by monitoring (130) window messages using an 
options such as minimizing to a particular monitor, to the appropriate hooking function to identify (132) a close win- 
closest parent application monitor or to the cursor's monitor. 15 dow message. When a close window message is identified, 
If such preferences have been selected, the desktop manager the desktop manager uses the window handle to trace (134) 
looks up (116) the preference parameters, creates (118) a the message back to its application and saves (136) the 
new display message reflecting coordinates of the selected current state (size/position) of the window in the registry, 
preference and the window is displayed (122). Otherwise, where the state information can be indexed to a particular 
the window is minimized (120) as specified by the operating 20 application. The desktop manager then continues to monitor 
system or application, i.e., according to the default window messages (130) to identify (138) an open window 
parameters, and the minimized window or icon is displayed message. Upon identifying such an open window message, 
(122) normally. lne desktop manager determines (140) the identify the 
... ...... application involved, determines (142) whether the applica- 

Simdarly, the maximization process is initiated by mom- tion ^ feled m the ^try ^ if ^ looks (144) lhe 

tormg (110) window messages using a SetWindowsHookEx 25 wind(W ^ mformation stan6 in me register and the 
API as described above. Upon identifying a maximization window is displayed (146) in the same state as when 
message, the desktop manager determines (126) whether the previously closed. Otherwise, the window message is 
user has selected maximization parameters. In this regard, released by the desktop manager and the default parameters 
the user may prefer to maximize a window, for example, to defined by the application are used (148) to display (146) the 

the full enhanced desktop, to the fiill display area of its 30 window. 

current monitor, or to the monitors) containing the window The code sections set forth in Table 4 illustrate how the 
corners. These preferences can be preselected by the user desktop manager implements this window saving feature: 

TABLE 4 

// NOTE IF THIS WINDOW HAS A "MEMORIZED POSITION" 

// 

awpWindowPosition[i].WindowName[0] - *\0'; 
awpWindowPosition(i].ClassName[0] = VY; 
if( strcmpfstring, "CabinetWdass") !° 0) 
{ 

ghooklnfo.bPositionMemory - TRUE; 

gbooklnfo.rectPosiLionMemory - awpWindowPosition[i].WiiidowRect; 

break; 

} 



COORDINATES 



} 

else 
{ 



// IF THIS WINDOW HAS A MEMORIZED POSITION, RECALL THE 

// 

x - ghooklnfo.rectPositionMemory.left; 
y - ghooklnfo.rcctPositionMemory.top; 

width - ghooklnfo.rectPositionMemory.right - ghooklnfo.rectPositionMemory.left; 
height « gbooklnfo.fectPositionMemory.bottom - ghooklnfo.rectPositionMcmory.top; 
ghooklnfo.bPositionMemory - FALSE; 



x - rectleft; 
y - recttop; 

width - rect right - rectleft; 
height - rectbottom - recttop; 



and stored in memory, or the options can be presented to the 
user as needed in the form of a pop-up window originated by 
the desktop manager application. The desktop manager then 
receives or looks up (116) the maximization preferences, 
creates (118) a new display message reflecting the coordi- 



The desktop manager of the present invention thus imple- 
ments a variety of object creation, reposition and resizing, 
65 and related placement functions that allow the potential 
benefits of the enhanced desktop environment to be more 
fully realized. Moreover, the desktop manager operates 
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quickly and substantially transparently, and handles a broad 
range of applications and window types. 

While various embodiments or implementations of the 
present invention have been described in detail, it is apparent 
that further modifications and adaptations of the invention 
will occur to those skilled in the art. However, it is to be 
expressly understood that such modifications and adapta- 
tions are within the spirit and scope of the present invention. 

We claim: 

1. A desktop managing method for use in a computer 
system including at least first and second monitors and a 
graphical user interface (GUI) operating system, the GUI 
operating system being operative for use in drawing objects 
on an enhanced graphical desktop wherein the enhanced 



30 



said graphical object relative to said desktop from a starting 
position to an end position and determining whether said end 
position extends over a border of said display area between 
said first and second monitors. 

6. A method as set forth in claim 1, wherein said graphical 
object comprises a child window. 

7. A method as set forth in claim 1, wherein said step of 
altering a selected display parameter comprises giving said 
graphical object a hidden form. 

8. A method as set forth in claim 1, wherein said step of 
conducting an analysis comprises intercepting a second 
graphical object message relating to said graphical object, 
wherein said first and second messages constitute at least a 
part of a drawing operation and said method further com- 



graphical desktop has a desktop area that includes a display is prises handling said first and second messages in a coordi 



area of the first and second monitors, said method compris- 
ing the steps of: 

monitoring graphical object messages passing in said 
computer system, said graphical object messages 
including assigned graphical object display parameters 
for a graphical object including assigned display coor- 
dinate information; 

altering a selected display parameter of a first graphical 
object message relating to said graphical object; 

separate from said step of altering, conducting an analysis 
relating to said assigned display coordinate information 
of said graphical object; and 

selectively changing said assigned display coordinate 



nated fashion so as to consistently treat elements of said 
drawing operation. 

9. A method as set forth in claim 1, wherein said step of 
monitoring comprises identifying a graphical object comple- 

20 tion message relating to displaying said graphical object, 
wherein said step of conducting an analysis is performed in 
response to said graphical object completion message. 

10. A method as set forth in claim 1, wherein said step of 
monitoring comprises identifying user originated messages 

25 relating to opening said graphical object. 

U. A method as set forth in claim 1, wherein said step of 
monitoring comprises identifying a keyboard input having 
an assigned object repositioning function and said method 
further comprises the step of repositioning said graphical 



information of said graphical object in response to said 30 object according to said assigned function 



analysis so as to fully display said object on one of said 
first and second monitors, wherein said process of 
altering a display parameter and separately analyzing 
coordinate information allows for consistent handling 
of drawing operations. 
2. A method as set forth in claim 1, wherein said graphical 
object is a child window associated with a parent window, 
wherein said parent window is held on one of said first and 
second monitors, and said step of selectively changing 



12. A method as set forth in claim 1, further comprising 
the steps of: 

providing a graphical representation of said enhanced 
desktop within said display area of one of said first and 
35 second monitors; and 

providing a symbol of said graphical object at a symbol 
location within said graphical representation of said 
enhanced desktop. 

13. A method as set forth in claim 12, further comprising 



comprises relocating said graphical object to the monitor 40 the step of moving said graphical object from one of said 



holding said parent window. 

3. A method as set forth in claim 1, wherein said assigned 
display coordinate information includes portions of each of 
said first and second monitors and said step of selectively 
changing comprises relocating said graphical object to the 45 
monitor including the greatest area of said graphical object. 

4. A method as set forth in claim 1, further comprising the 
step of minimizing said graphical object to a selected one of 
said first and second monitors. 

5. A method as set forth in claim 1, further comprising the 50 
steps of identifying user originated messages for moving 



first and second monitors to a different one of said first and 
second monitors by moving said symbol of said graphical 
object relative to said graphical representation of said 
enhanced desktop. 

14. A method as set forth in claim 1, further comprising 
the steps of receiving selected resizing coordinate informa- 
tion relating to resizing said graphical object and resizing 
said graphical object in accordance with said resizing coor- 
dinate information. 
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